The present invention relates generally to electronic messaging systems and, more particularly, to an electronic message delivery system for processing electronic messages from a sender to a recipient through the Internet.
Electronic Message Delivery Challenges
Electronic messaging has quickly become an integral part of everyday life in modern society. Today, electronic mail (e-mail) is the most widely used application of the Internet and the fastest growing communication medium. In addition to the dramatic expansion of one-to-one user correspondence, many companies have come to realize that regular outbound electronic message communication, as well as automated customer care services via e-mail, can strengthen a company's relationship with its customers. However, sending and receiving high volumes of e-mail presents a number of technical challenges such as, for example: 1) management and support of ballooning infrastructures for high volume sending; 2) maintenance of security on an application that is open to the Internet; 3) the need to apply virus, content and other filters to e-mail as it enters or departs the network; 4) management and prioritization of message queues; 5) the use of native customer data to trigger, target and define messages to customers; 6) management of inbound “bounced” e-mail; 7) the ability to consistently and automatically support customer preferences; and 8) executing delivery quickly and efficiently.
Meeting these challenges for scalable electronic messaging programs has been difficult, if not impossible, using available technology and has required substantial investment in hardware and human capital. Currently, companies and organizations of all types, including e-mail specialists and service providers, continue to deploy decades-old technology for sending and routing e-mail across the Internet via Mail Transfer Agents (MTAs) that did not anticipate the explosion in traffic volumes and system complexity of today's networks.
Prior-Art MTAS and Open-Source Mail Routing Servers
E-mail was developed to deliver electronic correspondence from one user to another on a computer network, where a user is a member of an e-mail messaging system and may be a person, a machine or an application having an e-mail address within the domain of the e-mail messaging system. The primary technology for e-mail is the TCP/IP communication protocol known as Simple Mail Transfer Protocol (SMTP), which was invented in 1981 and is designed to support the routing and delivery of electronic messages from a user of one computer to a user of a receiving computer via compatible routing delivery servers across the Internet. SMTP facilitated e-mail delivery by standardizing message formats with common headers and routing information and establishing command syntax and processes for communication transactions between e-mail handling applications.
In general, e-mail applications fall into at least one of three classifications that play a specific role in the process of moving and managing e-mail messages. The first application classification is a Mail Transfer Agent (MTA), which transfers e-mail messages between hosts and networks across the Internet using SMTP. A message may travel across several MTAs on its way to its intended destination. The second application classification is a Mail Delivery Agent (MDA), which transmits outbound messages to the MTA for delivery from the local host or network, and is invoked by the MTA to file incoming e-mail in the intended recipient's mailbox. In practice, many MTAs have an MDA built in, and some MDAs include certain MTA components. The third application classification is a Mail User Agent (MUA), which is essentially an e-mail client application that, at minimum, allows a user to read and compose e-mail messages from an MDA.1 
In the current state of the art, MTAs route e-mail messages from local hosts and networks through the gateway to the Internet to other MTA mail servers en route to recipients. MTA technology was developed by Eric Allman at UC Berkeley in the mid 1980's, and the basic architecture and components of the original MTA technology are still being used today.2 
MTAS—Current Art
In the current state of the art, the standard process for MTA e-mail sending is as follows:                1. At the MTA, accept an incoming SMTP-formatted message from an MDA or other e-mail generating application;        2. Write the incoming message to a file on the hard drive for temporary storage;        3. Read the message's SMTP headers for destination information;        4. Find the destination's mail exchange (MX) record through a Domain Name Service (DNS) lookup;        5. Open a connection (i.e., socket) with an MTA at the destination network;        6. Through this socket, conduct an SMTP communication consisting of a series of information transmissions from the sending MTA and replies from the receiving MTA, verifying identities and validating deliverability or communicating temporary or permanent deliverability failures;        7. Transmit the message; and        8. Await any short-term reply messages from the recipient MTA containing delivery failure errors (“bounces”). In the event of a delivery failure error, resend the message. Otherwise, delete the message from the hard drive and end the process.The sequence from connection to transmission is substantially uniform and standard in the current state of the art. The transmission of the message is the first part of a complete delivery process in which, after the message is transmitted, the MTA continues to store a copy of the message for a period in which any short-term failure messages (i.e., bounces), SMTP e-mails sent to the sending MTA from the receiving MTA communicating a delivery failure, may be received. If such bounces are received, the sending MTA uses the stored copy of the message to repeat the entire process and send the message again (i.e., retry). Typically, an MTA will retry a bounced message several times in succession before terminating the delivery process and forwarding a delivery failure message to the sender. This process may repeat while an e-mail is passed between MTAs en route from its origin to its final destination.        
Turning now to the figures, in which like items are indicated using like reference numbers, attention is initially directed to FIGS. 1A and 1B, which respectively illustrate prior art configuration and SMTP process for directing e-mail messages from a sender to a recipient. FIG. 1A illustrates a prior art, multi-user e-mail messaging system, generally indicated by a reference number 10, for sending and receiving SMTP e-mail through an MTA. System 10 includes a plurality of senders (represented by boxes 12A-12F) connected with a sender MDA 14. Senders 12A-12F generate a plurality of e-mail messages 16 and direct the e-mail messages to sender MDA 14. Each one of the plurality of e-mail messages 16 generally includes a header, which contains information about the originating sender (such as sender user name and sender server domain name) and the intended recipient (such as recipient user name and recipient server domain name), and a message body, which contains, for instance, the message text. Sender MDA 14 transmits e-mail messages 16 to a sender MTA 20. It is noted that specific components of sender MDA 14 and sender MTA 20, such as processors and hard drives, are not shown in FIG. 1A for simplicity. Sender MTA 20 initiates SMTP communication through the Internet (represented by a reference item 30) with a recipient MTA 40 so as to relay e-mail messages 16 to recipient MTA 40. Recipient MTA 40 forwards e-mail messages 16 to a recipient MDA 44, which then directs the messages to the respective, intended recipients, selected from one of a plurality of recipients (represented by boxes 46A-46F). The process as shown in FIG. 1A may be reversed such that recipients 46A-46F may generate a plurality of e-mail messages that are sent through the MDAs and MTAs to senders 12A-12F.
Referring now to FIG. 1B in conjunction with FIG. 1A, an SMTP process at sender MTA 20 for sending e-mail messages is illustrated. In a process 60 as shown in FIG. 1B, sender MTA 20 first receives an electronic message (i.e., one of the plurality of e-mail messages 16) from sender MDA 14 in a step 62. MTA 20 then writes the electronic message to its hard drive in a step 64. Then, in a step 66, MTA 20 looks up the domain name of the recipient server and connects to recipient MTA 40 in a step 68. A decision 70 determines whether the connection of sender MTA 20 with recipient MTA 40 has been made and, if the result of decision 70 is YES the connection has been made, then sender MTA 20 transfers a copy of the SMTP message on its hard drive to recipient MTA 40 in a step 72. If the result of decision 70 is NO the connection has not been made, then sender MTA may schedule a retry of the delivery (i.e., loop back to step 66) at a later time in a step 74. Following step 72, a decision 76 determines whether or not the delivery of the SMTP message to recipient MTA 40 has been successful. If the result of decision 76 is YES the delivery has been successful, then the delivered SMTP message is deleted from the hard drive of sender MTA 20 in a step 78. If the result of decision 76 is NO the delivery has not been successful, then sender MTA may again schedule to resend the message at a later time by looping back to step 74.
Continuing to refer to FIGS. 1A and 1B, it is noted that sender MTA 20 and recipient MTA 40 both act essentially as blind relays in this prior art configuration of an electronic message delivery system. That is, sender MTA 20 takes in pre-formed e-mail messages 16 and directs them through the Internet regardless of considerations such as the accuracy of the recipient user name and recipient server domain name and the availability of recipient MTA 40 to accept incoming e-mail messages. As a result, system 10 inevitably generates a plurality of bounces 50 which direct resends back through sender MTA 20, sender MDA 14 and to senders 12A-12F. The processing of bounces and resends consumes the available processing capability of the sender MTA and MDA and utilizes additional communication bandwidth while transmitting and receiving multiple e-mails during the process. Applicants submit that the aforedescribed process of bounces and resends uses undesirable amounts of processing time and bandwidth in the e-mail delivery system of the prior art.
Referring now to FIG. 2 in conjunction with FIG. 1A, the standard message format of an electronic message (such as one of the plurality of e-mail messages 16 shown in FIG. 1A) is illustrated. As shown in FIG. 2, each one of the plurality of e-mail messages 16 includes a message header 90 and a message body 92. In the example shown in FIG. 2, message 90 includes such information as the date of message generation, a message ID, originating sender (i.e., “From:”), intended recipient (i.e., “To:”), and others. Message body 92 includes, for instance, the message text and associated HTML code to specify the appearance of the message. In general, since each one of the plurality of e-mail messages 16 is directed to sender MTA 20 as a single file including the message header and message body, it is not possible to perform additional processes such as, for example, adding custom content, security keys or attachments at sender MTA 20.
To summarize, the key processes in e-mail MTAs in the current state of the art are as follows:                1. SMTP feed: the exclusive receipt and processing of pre-formed SMTP messages;        2. Store-and-forward: the mechanism of writing each message to a file on the hard drive for temporary storage, forwarding the file to the receiving MTA for delivery and subsequently deleting it after the completion of the delivery process to ensure recovery, and redelivery, in the event of a system failure before the delivery process had been completed;        3. Combined validation and transmission: a fixed sequence of communication transactions within the SMTP communication with recipient MTAs that culminates in message transmission;        4. Relay: a delivery process that sends each message it receives and continues to resend those that fail; and        5. Closed architecture: an architecture that combines the aforementioned elements in an uninterruptible sequence of processes.Recent Advances in the MTA Art        
The MTA processes and characteristics described above have not changed fundamentally since the first modern MTA application, sendmail, was released in 1981. To date, advances in the art of MTA e-mail delivery have not altered any of the fundamental processes and characteristics as described above, but have, rather, worked within their constraints to optimize delivery performance by improving the speed and efficiency by which these processes are performed.
To such end, recent advances in the art have developed in conjunction with advances in the functionality of hardware operating systems that support certain of the existing key processes for MTA e-mail delivery, namely, the generation of socket connections to recipient MTAs and the storage and retrieval of message files to and from the hard drive, or file input/output (i.e., file I/O).
The generation of socket connections is the foundation of SMTP mail delivery. In the earliest embodiment of the art, sendmail, the method for establishing a socket connection to a recipient MTA relied upon the creation of a new instance of the application for each new socket (i.e., process-based socket connection). This approach is inherently processor intensive and limits delivery speed to the rate at which the application can instantiate itself on the hardware.
Thread-Based SMTP Connections
As e-mail volumes have increased, and the practice of sending messages to large lists of recipients for publishing, marketing and other purposes emerged, interest in improving the speed and processing performance of e-mail MTAs has intensified. At the same time, advances in operating systems provided the ability to support multiple concurrent chains of commands within a program (i.e., threads), enabling concurrent processes in support of multiple simultaneous data transactions with substantially lower processing overhead than required for instantiation. Thus, an e-mail MTA could generate multiple socket connections simultaneously, enabling the parallel processing of SMTP connections for much faster delivery with much lower processing overhead (i.e., thread-based socket connection).
The open-source MTA application qmail is the earliest and most widely used example of this method. Subsequent improvements in threading models for various operating systems provided more efficient memory allocation for threading that enabled dramatic increases in the number of threads that could be efficiently used for socket connections. This increase in the number of threads led to the emergence of qmail-type MTA applications optimized to run most efficiently on operating systems configured for massively multi-threaded sending of electronic messages. The most successful examples of this advance are the commercial products PowerMTA™, released in 1999, and Lyris MailEngine, released in 2001.
Asynchronous File I/O
Improvements in speed and performance arising from multi-threaded SMTP communications highlighted a new rate-limiting process in MTA e-mail delivery, the process of writing and retrieving message files to and from the hard drive, file I/O. File I/O processes are common across computer applications, and the propensity of the speed of an application, or series of processes, to slow down or bottleneck behind the sequential reading and writing of files to disk is widely known. A first significant advance in this process introduced the management of data storage across multiple drive discs in parallel (RAID), dramatically increasing speed. A second, more recent, advance in this process, released in open-source operating systems OpenBSD and Linux RedHat, enables the operating system to read and write multiple files to and from a drive simultaneously in increments, or asynchronously (i.e., asynchronous I/O). This advancement enables much more rapid reading and writing of files to disc, creating a marked improvement in efficiency for the file I/O processes in MTA applications, thereby improving processing speed and efficiency.
Thus, it became possible to optimize a qmail-based MTA application on an operating system that supports massive multi-threading and asynchronous file I/O to achieve the best performance to date from an e-mail MTA application. In fact, to ensure the optimum configuration of the operating system and tuning of the MTA application, the preferred embodiment of such an application is a pre-configured hardware appliance with RAID. Two such appliances were launched in 2001-2002: IronPort A60™ and Mirapoint Message Server. A comparison of the sustained performance of the prior art MTA applications described above, according to the published specifications, is summarized in TABLE 1.
TABLE 1E-Mail MTA PerformanceSustained PerformanceOptimized(Standard dual processorQ-mail-PIII or equivalent)Sendmailqmailbased MTAsIronPortE-mails (10,000 bytes)/10,00030,000200,000300,000server/hourServers required to501732send 4,000,000 e-mailsin an 8 hour period
The most common performance metric for MTAs is the sustained rate at which they transmit standard text messages (ranging from 5,000 to 10,000 bytes) from a standard dual Pentium 3 or Pentium 4 processor server, or an equivalent thereof. The Sendmail MTA performs the most poorly, as its speed is impaired by instantiation for socket connections and standard file I/O processing. Standard implementations of qmail perform about three times better, through the use of thread-based socket connections. Qmail-based multi-threaded MTAs offer a dramatic ten-fold improvement in performance over standard implementations of qmail while qmail-based multi-threaded MTAs that also use asynchronous I/O offer an additional 50% or more increase in performance over massively multi-threaded qmail-based MTAs without it.
Application Program Interfaces for the MTA
While sendmail and other MTAs evolved to use features and rule sets for content analysis, options available to users in performing modifications to SMTP messages and other complex processing (such as, for example, spam and attachment filtering, custom logging, disclaimer addition and virus scanning) have been limited to: 1) calls to external programs, which are generally usable only for local delivery or messages to local addresses; 2) use of the MTA in queuing mode with a program that is triggered on a regular basis; 3) use of a forwarding scheme (i.e., serial architecture with several MTA instances); or 4) altering sendmail's source code to add some extensions, thereby requiring recompilation of sendmail.3 None of these four options are simple to use or efficient in operation. Lacking common interfaces to other application, this architecture is also referred to as a “closed architecture.”
In order to facilitate the writing and integration of processing filters for e-mail, the sendmail team developed some application program interfaces (APIs) for enabling the introduction of external e-mail processing sequences at various steps in the SMTP process of the MTA.4 These APIs were collectively called MILTER (Mail Filtering API). MILTER was first implemented in version 8.10.x of sendmail and has been officially supported in sendmail since version 8.12.x.
The MILTER API is limited in scope to post-processing, in which an API event is triggered only after each SMTP event occurs during the protocol (e.g., Connect, HELO, MAIL FROM, RCPT TO, DATA and QUIT). That is, messages may be acted upon while traveling INBOUND into a server, when a receiving server is responding to the actions of a sending server. However, there is no provision for acting upon messages before an event occurs and, consequently, there is no facility for acting upon messages traveling OUTBOUND from a server when a sending server is initiating actions.
As will be seen hereinafter, the present invention provides a remarkable improvement over the prior art as discussed above by virtue of its ability to provide increased performance while resolving the aforedescribed problems present in the current state of the art electronic message delivery systems.
References
    1. Bill Ball, Hoyt Duff, Red Hat® Linux 9, Sams May 8, 2003, Chapter 11.    2. David Pitts and Bill Ball, Red Hat® Linux 6 (Unleashed), Sams Jul. 30, 1999, Chapter 7 SMTP and Protocols.    3. Stéphane Lentz, “Milter,” http://milter.free.fr/intro/, slides 1 and 2, France, Apr. 14, 2004.    4. Sendmail, Inc., “Milter API,” http://www.milter.org/milter api/api.html, 2003.